Generic season index - no season is length 0 #1845
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… season_length is 0 even if no start was found
aulemahal
changed the title
5 tasks
coxipi
reviewed
Aug 1, 2024
Co-authored-by: Trevor James Smith <[email protected]>
coxipi
reviewed
Aug 1, 2024
coxipi
reviewed
Aug 1, 2024
Co-authored-by: Trevor James Smith <[email protected]>
coxipi
reviewed
Aug 1, 2024
aulemahal
added a commit
that referenced
this pull request
Oct 10, 2024
<!--Please ensure the PR fulfills the following requirements! -->
<!-- If this is your first PR, make sure to add your details to the
AUTHORS.rst! -->
### Pull Request Checklist:
- [ ] This PR addresses an already opened issue (for bug fixes /
features)
- This PR fixes #xyz
- [x] Tests for the changes have been added (for bug fixes / features)
- [x] (If applicable) Documentation has been added / updated (for bug
fixes / features)
- [x] CHANGELOG.rst has been updated (with summary of main changes)
- [x] Link to issue (:issue:`number`) and pull request (:pull:`number`)
has been added
### What kind of change does this PR introduce?
Implements `resample_map`. This function is meant for all
`da.resample(...).map(...)` calls. These, `flox` cannot improve
automatically so we use some flox logic to help. The idea is to map the
resample-map construct on each block in parallel. This is possible by
first rechunking the array so that chunks boundary fit with resampling
period boundaries (this is a flox function).
The main improvement should come from the fact that `map_blocks` hides
much of the complexity to `dask`, so the resulting graph is much
lighter. I still have to better test the performance of this. My goal
would be to have some short text in xclim's doc that highlights when the
option is useful and when it is not. The option is activated through
`set_options`.
The current function works only when the input object is of the same
type as the output one. So some functions couldn't be wrapped with this
yet. The most important untouched code for the moment is the missing
checks where I think this could help a lot.
### Does this PR introduce a breaking change?
It should not. This is completely optional.
### Other information:
In progress, I still need to prove the performance boost.
This depends on #1845 because I need all improvements for PC.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull Request Checklist:
number) and pull request (:pull:number) has been addedWhat kind of change does this PR introduce?
generic.season, a generic index function for computing the start/end/length of seasons. Based onrun_length.seasonbut with units management and the comparison.run_length.seasonintoseason_start,season_end, plus the existingseason_length. The idea of grouping code together was good, but it added a lot of unnecessary computations when only one facet is needed (i.e. most cases). I think I was able to divide it elegantly, using only one magic fast path.frost_free_season_startandfrost_free_season_end. Those were not respecting the "season" definition. Now they do.Does this PR introduce a breaking change?
frost_free_season_startandfrost_free_season_endhave changed. Their notion of "season" is not more strict. I think the difference not significative for most cases. No tests needed a change, but again our tests are very simple.All season length indicators will now return 0 when no season is found (no start). Previously, when no start was found we returned 0 when an end was found and
nanotherwise. I think the idea was to assume that neither end nor start meant the data was probably wrong. But that's the job of the missing checks, not therun_lengthhelper. Thus I applied the more logical rule : no season == 0 length.I have reverted some changes of #1796, I'm sorry. I'm trying to generalize the indicators and it made more sense that all aspects of the same "growing season" were using the same exact arguments.
Other information:
This allows indices to use run length function that return a DataArray after being called with a DataArray. This "type preservation" will be quite handy in my next PR, stay tuned!
Sadly, this branch is based off #1838 because I need both for PC.
Ugh
The amount of copied docstring text and signatures is ridiculous. I really want to remove all those one-liner indices and only keep the indicators. But I fear this would be too breaking of a change as it would remove elements from the API.
Right now, we have inconsistent indicators with inconsistent documentation because everything was copy-pasted by hand with incremental changes that were not always ported back to the other indices.